feat(sdk-logs): Add Logger Configurator API & Trace-based + Min-Severity Filtering #5991
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5991 +/- ##
==========================================
+ Coverage 95.40% 95.41% +0.01%
==========================================
Files 317 318 +1
Lines 9392 9444 +52
Branches 2167 2183 +16
==========================================
+ Hits 8960 9011 +51
- Misses 432 433 +1
🚀 New features to boost your workflow:
|
pichlermarc
left a comment
pichlermarc
left a comment
There was a problem hiding this comment.
@JacksonWeber - please also mark all features that are marked as in-development in the spec as @experimental in the TSdoc. This way we can avoid blocking https://github.com/open-telemetry/opentelemetry-js/milestone/19
Experimental features have been marked as such. Thanks for the feedback! |
pichlermarc
added
the
spec-feature
pichlermarc
left a comment
pichlermarc
left a comment
There was a problem hiding this comment.
Hmm, overall I'm a bit confused by this feature - the spec for it seems still a bit vague and seems to duplicate functionality from existing features. 🤔 That's not this PR's issue, I feel like it's a symptom of a spec that's not quite where we'd need it to be yet.
I suppose the value proposition for having a LoggerConfigurator is to save on allocations in the pipeline - which is important for a hot path like this. (Q: @JacksonWeber is this the motivation for working on this feature?) If that's not the goal, then we could accomplish the same thing today in the LogRecordProcessor.
Though it seems to me that the optimizing LogRecordImpl to avoid expensive operations until it's properties are first accessed, and then applying filtering in the LogRecordProcessor may be a better way to go about it without adding additional concept to the public API.
The Go SIG seems to have a similar stance: open-telemetry/opentelemetry-specification#4644
| // Get logger configuration | ||
| const loggerConfig = this._sharedState.getLoggerConfig( | ||
| this.instrumentationScope | ||
| ); |
There was a problem hiding this comment.
Given that emit is a hot-path, I think we should optimize here wherever possible.
One thing I noticed is that the way it's implemented right now is:
- we call getLoggerConfig()
- if it has already cached something for this Logger, it will always return that initial config
- dynamic updates are therefore not possible
Do we need the map lookup or should we just cache it in the logger? 🤔
There was a problem hiding this comment.
The primary motivation for this feature work is just to get an implementation of trace-based log sampling and minimum severity-based log sampling implemented in a way that's easy for users to enable as part of the configuration of their LoggerProvider.
Thanks for the link to the issue in the Go repo, I'm happy to refactor this PR to avoid the creation/usage of the LoggerConfigurator and just implement these two filtering strategies in the LogRecordProcessor.
There was a problem hiding this comment.
@pichlermarc the PR has been updated to just add a new logRecordProcessor that handles both types of filtering. Please review when you have a chance.
There was a problem hiding this comment.
@pichlermarc per our conversation in the JS SIG today I've reverted the changes here back to following the spec (creating the logger configurator).
JacksonWeber
changed the title
loggerConfiguratorFilteringLogRecordProcessor
JacksonWeber
force-pushed
the
jacksonweber/logger-sampling
branch
from
12fb209 to
8e25840
Compare
JacksonWeber
changed the title
FilteringLogRecordProcessor2 participants
Which problem is this PR solving?
This pull request introduces advanced logger configuration capabilities to the OpenTelemetry JS SDK Logs package. The main feature is the new
LoggerConfiguratorAPI, which allows users to filter logs by minimum severity, trace sampling status, and to configure loggers individually using pattern matching. These changes improve flexibility and control over log processing and exporting.Logger configuration and filtering features
LoggerConfiguratorAPI, enabling users to define per-logger configuration for severity filtering, trace-based filtering, and logger disabling, with pattern matching for logger names. (experimental/packages/sdk-logs/src/config/LoggerConfigurators.ts,experimental/packages/sdk-logs/src/types.ts,experimental/packages/sdk-logs/src/LoggerProvider.ts,experimental/packages/sdk-logs/src/internal/LoggerProviderSharedState.ts) [1] [2] [3] [4] [5] [6]Loggerclass to apply minimum severity and trace-based filtering before emitting log records, dropping logs that don't meet the configured criteria. (experimental/packages/sdk-logs/src/Logger.ts) [1] [2]Documentation and API updates
README.mdwith detailed documentation and usage examples for the new logger configuration features, including severity and trace-based filtering and per-logger configuration patterns. (experimental/packages/sdk-logs/README.md)LoggerConfig,LoggerConfigurator, andcreateLoggerConfigurator. (experimental/packages/sdk-logs/src/index.ts) [1] [2]Changelog and test updates
loggerConfiguratorfeature. (experimental/CHANGELOG.md)experimental/packages/sdk-logs/test/common/Logger.test.ts)Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist: